1. Field of the Invention
The present invention relates generally to a mobile broadcasting system, and more particularly to a method and a system for distributing a traffic encryption key for a mobile broadcasting service that is applied to a service protection and content protection structure such as a smart card profile in an Open Mobile Alliance Broadcast (OMA BCAST).
2. Description of the Related Art
In the mobile communication market, production of new services through recombination and integration of existing technology has been in continuous demand and communication and broadcasting technology has developed to enable a broadcasting system or a mobile communication system in the related art which provides a broadcasting service through a mobile terminal (hereinafter “terminal”) such as a cellular phone, a PDA, and the like. Under the conditions of latent and actual market demands, such as an abrupt increase in user requirements with respect to multimedia services, enterprise strategies that intend to provide new services such as broadcasting services in addition to the existing audio services, and interests of IT enterprises that strengthen the mobile communication business to accommodate the consumer requirements, the fusion of mobile communication services and IT technologies has occupied a position as the big flow of the next-generation mobile communication technology development.
The Open Mobile Alliance (OMA), is an application standards group which makes and researches standards for mutual interlocking of individual mobile solutions, and serves to determine diverse application standards for mobile communication games, Internet services, and the like. In particular, the OMA BCAST Working Group of the OMA Working Group has studied technologies for providing broadcasting services using terminals. Hereinafter, a broadcasting system that is discussed in the OMA BCAST Working Group (hereinafter “mobile broadcasting system”) will be briefly described.
FIG. 1 is a block diagram illustrating the network configuration of a general mobile broadcasting system. In FIG. 1, a Content Creator (CC) 10 is a BCAST service content provider (hereinafter “content provider”). The BCAST service may be an existing audio/video broadcasting service, file (music file or data file) download system, and the like. A BCAST Service Application (BSA) unit 20 serves to receive a supply of BCAST service data from the content provider CC 10, processes the data in a form suitable to the BCAST network of FIG. 1, and generates the BCAST service data. The BSA unit 20 also serves to generate standardized metadata that is necessary for guiding the mobile broadcasting service. BCAST-1 to BCAST-8 are interfaces among entities.
In FIG. 1, a BCAST Service Distribution/Adaptation (BSD/A) unit 30 serves to set a bearer which will transmit the BCAST service data that is provided from the BSA unit 20, to determine a transmission schedule of the BCAST service, and to generate a mobile broadcasting guide. A BCAST Subscription Management (BSM) unit 40 manages device information on terminals that receive subscription information of subscribers for receiving the BCAST service, BCAST service providing information, and the BCAST service.
In FIG. 1, terminal 50 is a terminal that is capable of receiving the BCAST service and connecting to a cellular network according to the performance of the terminal. Broadcast network 60 is a network that transmits the BCAST service, such as a Digital Video Broadcasting—Handheld (DVB-H), a Third Generation Partnership Project Multimedia Broadcast and Multicast Service (3GPP MBMS), Third Generation Partnership Project 2 Broadcast and Multicast Service (3GPP2 BCMCS), or the like. An interaction network 70 is a network in which the BCAST service is transmitted in a one-to-one manner, or control information and additional information related to the reception of the BCAST service are bidirectionally exchanged, and for example, it may be the existing cellular network.
In general, in the BCAST service, a server that manages the broadcasting service transmits encrypted service data, and a plurality of terminals receives the data. In this case, the plurality of terminals can use the corresponding service by decrypting the encrypted service data provided from the server using a predetermined cryptographic key pre-stored in the terminals. In relation to this, a method of encrypting broadcasting content and services is briefly divided into two sides of service protection and content protection.
On the other hand, the OMA BCAST Source Production Control Parameter (SPCP) smart card profile implements a key management scheme for a mobile broadcasting service. For access provisioning, two kinds of keys, i.e. Long Term Keys (LTKs) and Short Term Keys (STKs) are defined. The LTKs are used to perform conditioning of accesses for the STKs by encrypting the STKs according to the LTKs based on the user service subscription plan. The STKs are used for the actual traffic encryption. Although the LTKs and the STKs should be periodically updated, the lifetime of the LTKs is far longer than the lifetime of the STKs. The LTKs are provided to a user by the BSM, and the STKs are transmitted to a user by the BSD/A unit 30. Such a key management scheme is problematic in that frequent STK updates increase high bandwidth consumption.
Hereinafter, key management in a smart card profile will be described in detail.
FIG. 2 is a diagram illustrating a key hierarchy defined in a general smart card profile.
A Subscription Management Key (SMK) 120 is derived as the result of user authentication according to the reception of registered keys 110, and protects the LTK transferred through a Long Term Key Message (LTKM). The LTKs of the smart card profile may include a Service Encryption Key (SEK) 130 and Program Encryption Keys (PEKs). These two kinds of keys have different lifetimes to support different service access scenarios.
The SEK 130 is provided to a user who has subscribed to the service. That is, as successive authentication is performed, content and periodically updated SEKs are continuously provided to the user even without a separate request. This scenario is also called “subscription-based access”.
The PEKs 140 are provided to a user whose access to a certain service is limited to a program that has a specified time interval or service unit. In order to obtain access qualifications for the next program or the consequent time interval, a user should make an additional purchase request. The program or the time interval may be related to one or more PEKs. This scenario is called “Pay-Per-View (PPV)-based access”.
A Traffic Encryption Key (TEK) 150 is the STK which is carried through a Short Term Key Message (STKM), and encrypted by the SEK. Also, the TEK is carried through the STKM and is encrypted according to the PEK 140. The STKM is authenticated using the PEK 140 that is carried through the STKM and is encrypted according to the SEK 130. The TEKs 150 are frequently updated for security.
FIG. 3 is a diagram illustrating the supply flow of SEKs and TEKs under general subscription-based access conditions.
Under the subscription-based access conditions, the lifetime of the SEK (SEK LT) is calculated as n multiplied by the lifetime of the TEK. Before the SEK (SEKy−1) expires, the BSM generates and transmits a new SEKy to a subscribed user in the LTKM in step 210. The SEKy is encrypted according to SMK1 that is shared only between the user and the BSM. After the SEK (SEKy−1) expires, the PEKs which are carried together with TEKx+1 to TEKx+n through the STKM are encrypted by the SEKy. Also, before the SEKy expires, The BSM generates and transmits a new SEKy+1 to a subscribed user in step 220.
FIG. 4 is a diagram illustrating the supply flow of SEKs and TEKs under general PPV-based access conditions.
Under the PPV-based access conditions, the lifetime of the PEK (PEK LT) is calculated as m multiplied by the lifetime of the TEK (where, m≦n). Also, in this embodiment, the lifetime of the PEK is PEK LT=0.5*SEK LT. Accordingly, the PEK should be updated more frequently than the SEK, e.g. twice as frequently as the update of the SEK.
If a user issues two purchase requests with respect to the two consequent time intervals which are related to PEKz and PEKZ+1, the BSM transmits the LTKM including the PEKz to a user in step 310 before the TEKx+1 (the first TEK related to PEKz) is used. The PEKz is encrypted according to the SMK2 that is shared only between the user and the BSM. Also, the BSM transmits the LTKM including the PEKz+1 to a user in step 320 before the TEKx+m+1 (the first TEK related to PEKz+1) is used. However, if no further purchase request is issued by the user before the TEKx+n+1 is used, the BSM does not transmit the PEK for the TEKx+n+1 to the user, and thus the user cannot decode the TEKs starting from TEKx+n+1.